AWS Media Servicesを使ったラスベガスからの動画配信2019 ~不安定な配信の裏側で何が起こっていたのか~ #reinvent
はじめに
清水です。昨年2018年に引き続き、今年2019年もAWS re:Invent2019の会場であるラスベガスから「Developers.IO 2019 in Las Vegas」を開催しました。私も昨年に引き続きAWSインフラならびに配信まわりを担当させていただきました。今年は配信中にネットワークトラブルに見舞われてしまい、映像や音声が乱れてしまうなどお見苦しい配信になってしまいましたが、そのとき何が起きていたのか、どんな対策が取り得たのか、などについてもまとめてみたいと思います。
なお、昨年2018年の配信については以下をご参照ください。
全体構成について
まず全体構成についてですが、 基本的には昨年2018年と同じ構成となります。ラスベガス配信においてどんな点が課題になるのか、課題を解決しつつラスベガスで配信するにはどうしたら良いのか、などの試行錯誤については昨年のエントリを参照していただくとして、本エントリでは要点のみまとめてみたいと思います。
構成図としては下記となります。
全体構成のポイントは次のとおりです。
- 配信エンコーダ
- 作業用PCと兼用のMacBook ProでOBS Studioを稼働
- ネットワーク
- ホテルのWi−Fiを利用（上限数Mbps）
- 配信解像度、ビットレート
- ネットワーク環境を考慮し、配信ビットレートを上限1Mbpsと想定。これに合わせて解像度も640x360、コンテンツを考えてフレームレート10FPS。音声は128kbps
- AWS構成
- リージョンはオレゴン（us-west-2）を利用
- 配信構成はMediaLive -> MediaStore -> CloudFront
- 視聴ページ
- AWS re:Invent 2019 JAPAN PORTALに動画プレイヤー(Video.js)を埋め込む
- ポータルサイト管理者の知恵蔵と連携
機材について
配信用機材については昨年から見直し、少しだけ変更しています。どういった経緯でどのように変更したか、以下にまとめてみます。
まず前提として、昨年同様にWebカメラ＆スピーカーマイク（Web会議に利用するもの）を作業用兼配信用MacBook Proに接続しOBS Studioに認識させる、という点は変わりありません（機材の都合上、この変更が難しかったのです）。ただ昨年の配信を振り返り、少しでも画質を向上させたい、という声が挙がりました。昨年は真っ赤のスタジャンだったのですが、会場の明るさやカメラの画質などからピンクっぽい写りになってしまっていたのです。この点を少しでも改善するのが狙いです。とはいえ、前提となる「Webカメラである」という点は変えられません（ビデオカメラ等の接続はできない）。そしてこのWebカメラは色味などの調整を行うことが容易ではありません。このことを弊社マーケティングチームに伝えたところ、ならばまずは会場の明るさを上げよう！、ということで以下のようなLEDリングライトを（日本から持ち込んで）ラスベガスの現場に用意いただきました！（感謝！）
またWebカメラについてですが、昨年は画角重視（より広角で撮りたい）ということでBUFFALOの広角120度対応のものを利用しました。（おそらく以下の商品だったかと思います。）
今年は少しでも画質を良くできれば、ということでLogicoolのC920rを用意しました。
2つのWebカメラを比べると、BUFFALOの製品は広角120度が売りということで、Logicool C920rよりも広く撮影ができます。対してLocicool C920rは画角は狭くなりますが、BUFFALの広角Webカメラよりも画質が良いです。その他、BUFFALOの広角Webカメラは手動でフォーカス変更、Logicoolはオートフォーカスなどの違いがありますが、今回は画質重視ということでLogicool C920rを前提に考えました。
スピーカーマイクについては昨年と同様、Web会議などに利用しているJabra Sepakです。細かな違いとして、昨年はSpeak 410でしたが、今年はSpeak 510を使いました。Speak 510はBluetooth接続できる点がSpeak 410との大きな違いかと思いますが、Bluetoothは無効にしUSB接続していますん。そのため実質的な違いはあまりないのかな、と思っています。
現地での下見について
ラスベガス現地に到着した2019/12/01(日)の夜、配信現場の下見を行いました。今年も会場はF-Secure様のご厚意でお借りしました、Venetianホテルのスイートルームです。（ありがとうございます！）今年はなんと最上階の36階でした！
下見の日時ですが、各メンバーの都合やF-Secure様のご都合が良いタイミング、という点もありますが、その中でも会場の明るさを確認するため配信本番と同様の時間帯（つまり日中ではなく夜）とさせていただきました。また実際の配信は現地水曜日の夜となりますが、なるべく早いタイミングで下見を行っておき、例えばもしホテルのWi-Fiがまったく使用できない（あまりありませんが、RTMP接続がブロックされている等）の場合に対策を考える時間を確保する、といったことも考えていました。
下見では照明とカメラマイク等機材の位置決め、また実際に配信を行い問題がないことを確認します。機材の位置決め、特にカメラの位置決めについて今年は少し気を使いました。WebカメラをLogicool C920rにすることで、昨年使ったBUFFALOの広角Webカメラよりも画角が少し狭まります。椅子の数やカメラの位置を具体的に確認し、配信当日に出演者の方が見切れてしまわないようにしました。なお配置的に広角でないと無理、となった場合に使うことも想定して、現地には予備としてBUFFALOの広角Webカメラも持ち込んでいました。（けっきょく今回は出番がありませんでしたが。）カメラにや椅子などにあわせて、LEDリングライトやその他の機材も配置場所を決め、実際に映像を配信して確認を行います。カメラや照明の位置などに問題がないことを確認しつつ、テストとして30分強ほど配信を続けて問題がないことを確認しました。（実際は配信本番時にネットワークが不調となりますが、この段階ではネットワークにも問題はなかったのです……。）
実際の照明（LEDリングライト）、カメラマイクなどの配置は以下のようになりました。（写真撮影しそびれていたこともあり、右の写真は配信本番のものになります。）
| 左手に出演者さんが見える視点から | 出演者の方の視点から（実際は配信本番時のセッティング） |
|
|
これで照明やカメラマイク、そして出演者の方がの位置（椅子の位置）が決まりましたが、配信本番にこれを忘れてしまっては困ります。配信当日に位置がわかりやすいよう、養生テープで印をつけさせていただきました。（快諾いただいたF-Secure様、ほんとうにありがとうございました。助かりました。）
実際の配信と、配信時に発生したトラブルについて
さて実際の配信です。配信ページ（ポータルサイト側）を10分前には更新ができるよう、OBS Studio側で「まもなく始まります！」のフタ画像の配信にして、本番開始までスタンバイしていました。そして現地で19時を回ったタイミングでフタ画像を外して出演者の方に喋り始めてもらう、という段取りでした。
19時ジャストのタイミングでOBS Studioを操作してフタ画像から実際の映像に切り替えます。と同時に、OBS Studioの右下、配信状態を示すアイコン（ネットワークに問題がなければ緑、ネットワークに問題があれば赤が表示される）が赤色になる、というトラブルが発生しました。
こちらが通常時の緑の状態です。配信前のネットワークが安定しているタイミングに撮影した写真になります。
下見、当日の配信準備含めてこれまで発生していなかったネットワークに問題ある赤の状態が、あろうことか配信開始と同時に発生してしまいました。
フタ画像の配信状態が変化の少ない映像であり、映像の切り替わりで一時的に映像ビットレートが増え、少しネットワークに負荷がかかったのかな……、と考えたのですが、どうやら一時的ではなく、ネットワークが不調の状況は続きます。けっきょくこのネットワーク不調は配信が終わるまでの1時間、断続的に続くものでした。
どのぐらいネットワークが不安定だったかは、以下のMediaLiveのChannelリソースについて、CloudWatchメトリクスでの参照結果がわかりやすいかと思います。オレンジがChannelへのNetwork Inのメトリクスです。（実際の配信本番がこちらのスクリーンショットでは3:00-4:00、それ以前の1:30ごろからはテスト用の配信、2:15-2:30ごろはいちいど配信を停止していた時間帯になります。）
最終的な（配信を停止する直前の）OBS Studioのステータスは以下になります。およそ1割強のがドロップフレームとなってしまいました。
OBS StudioからMediaLiveへはRTMPで映像を送信していますが、このネットワーク不調の間、接続自体（コネクション）が切断されるということはありませんでした。（OBS Studio側で配信終了となり、再度配信を開始する必要がある状態にはなりませんでした。）それでもOBS Studioから本来であれば1Mbps前後でMediaLiveに映像を送り続けるつもりが、想定以下の（例えば100kbps前後での）帯域しかでずに、すべてのデータを送信しきれていない状況は続きます。このため、実際にMediaLive->MediaStore->CloudFrontを通して配信される映像については、まず映像が真っ黒になり音声だけの状態となり、さらにネットワーク不調が続くタイミングでは音声が途絶え途絶えの状況になるという具合でした。
私はOBS Studioが稼働しているMacBook Proとは別の、iPhone XS上で実際に配信される動画の視聴確認をしていました。ネットワークとしてもMacBook Pro（VenetianホテルのWi-Fi）とは別、AT&Tの回線につながっている状態のものです。この自分の視聴環境でも配信映像が不安定になることが確認でき、また日本で視聴していた社内メンバーからも社内チャットで同現象の連絡（映像が真っ黒になる、音声が途切れる）の報告をいただきました。
ネットワーク不調の原因として考えられること
このネットワーク不調ですが、OBS StudioのRTMP接続が途切れるわけではなくデータは送り続けているが帯域が減少していること（本来1Mbps前後で送るはずが数百kbpsしかでていないこと）、すこし時間が経つと復調することなどから、現場のネットワーク（VenetianホテルのWi-Fi）の不調であると現場では断定しました。ホテルのWi-Fiは時間帯や他のホテルの宿泊者の使用状況等によって速度がでなくなることがある、ということが頭にあったのも断定した要因です。また以前、日本国内での配信ですがWi-Fiの調子が悪い状況で同様の、映像が黒くなりやがて音声が途絶え途絶えになる、ということを経験していたことからもこの考えに至りました。
なお現場では、AWS環境の不調はあまり考えなかったのですが、これも確認するのがベストではあったのかなと（後からですが）思います。とはいえ、やはり配信現場ではリソースが限られており、今回のケースではそこまで確認するすべがなかったのですが。
対策として行動に移せたこと、移せなかったこと
このネットワーク不調が発生し、実際に私が配信現場で行動に移せたこと、移せなかったことをまとめてみます。まずは配信を担当していたマーケティングチームメンバー（出演者ではない）に状況を伝えました。社内チャットで連絡できればベストだったのですが、作業用兼配信用MacBook Proはブラウザで社内チャットを開いておらず、ここにさらにネットワーク負荷をかけることがためらわれました。スマホを使うことも考えたのですが、焦っていることもあり素早く伝えるのが難しいと考え、実際は口頭で伝えました。ただ実際に配信している現場であるため、この会話が配信に入らないよう小声でつたえる必要がありました。その後、マーケティングチームメンバーから社内チャットで出演者の方にも状況が伝えられ、さらに出演者の方から口頭でネットワーク不調で配信が安定していない旨、配信を通して視聴者の方に伝えていただくこととなりました。
続いて、本編が始まってすぐにこのネットワーク不調の状況になったため、どこかで配信が途絶えてしまう（映像が長時間真っ暗状態となり、音声も途絶え途絶えから、完全に途絶えてしまう）懸念がありました。幸い今回はここまでひどい状態にはなりませんでしたが、それでも見苦しい映像・音声になってしまっていることは確かです。後述しますがネットワークの状況を変える手段がなかったんため、ライブ配信については現状のままとし、後日アーカイブをVODで公開できないか、ということを考えます。この場合、アーカイブを収録しているか否かがポイントとなります。また今回のネットワーク不調ではMediaLiveに映像がとどいていないため、MediaLiveからS3に出力しているアーカイブについても配信同様、映像が真っ黒になったり音声が途切れ途切れになっているという状況は変わりません。現場でネットワークを介さず別手段で収録しているかどうか、となります。今回は幸いなことに、マーケティングチームでスマホを使い、配信用機材とは完全に別系統（カメラやマイクなども別）で収録をしていただいていましたので、これを後日VODとして公開する運びとなりました。
以上がネットワーク不調のトラブルに対して、実際に行動に移せたことです。対して行動に移せなかったこととしては、実際のネットワーク不調に対する改善策となります。配信現場にはホテルのWi-Fiの他、モバイルWi-Fiルータ、または現地SIMを入れているスマホのテザリング機能がありました。ただ、昨年はホテルのWi-Fiで問題なく配信が行えていたこと、また今年も下見の段階ではホテルのWi-Fiで問題がなかったことから、モバイルWi-Fiルータ、現地SIMでのスマホのテザリングとも動作確認をしていませんでした。感覚的にもどちらもモバイル回線であり、それほど安定した回線ではない印象だったこともあります（実際、現地SIMのモバイル回線で視聴確認はしていましたが、たまに映像が止まりリロードする必要がある、という具合でした。）そのため、本番配信中に使用しているホテルのWi-Fiが不調ではありながら、代替となるネットワークに切り替える、というアクションが起こせませんでした。配信機材としてもOBS Studioが1系統のみとなりますので、ネットワークを切り替えることは一度配信を止める必要が発生します。ネットワークを切り替えたところで安定するとは限らないこと（もしかしたらモバイル回線が安定せずさらに不調になる可能性もある）、それをいったん配信を止めてまでやったところで状況が改善するかの確信が持てず、けっきょくネットワーク不調自体に対しては何も打つ手がなかった、という状況でした。
ネットワークトラブルに対して、事前の対策としてどんなことができるか
最後に今回のネットワーク不調トラブル、今後同様のことをやるとしたらどんな対策が取れるのか、という点で考えていみたいと思います。とはいえ、まずは映像配信用の安定した（必要な帯域がでる）回線を用意することに尽きるかなと考えます。可能であれば配信機材となるMacBook ProとWi-Fiではなく有線接続できる、ホテルのインターネット回線など共用の回線ではないものが望ましいですよね。ただ、実際問題そんなインターネット回線をVenetianのホテルなどラスベガスの配信現場に用意できるのでしょうか……。それが用意できない、（今回のような）環境での配信を行うということについても考えてみましょう。1つは今回のモバイル回線のような、サブとして利用できる回線をきちんと準備しておくこと、また仮に今回のようなメイン回線のネットワーク不調が発生した場合に切り替える手順を準備しておくことかと考えます。実際に配信中にネットワーク不調が起こった場合、混乱などから実際に切り替え判断が難しいかと考えます。事前にどんな状況なら切り替える、切り替えないということを決めておくことが重要かと思いました。またネットワークから先、AWSインフラや配信ページ上も含めて、仮に配信現場のネットワーク切り替えが発生した場合にそのショックを最低限にすることができないか、考えておくことも有用かと思います。もう1つ、考えられたのは複数回線を束ねて使う「ボンディング」が利用可能な機材を使用することです。ざっと調べたところ以下のような機材がありました。いずれも複数の回線（Wi-Fiやモバイル回線）を束ねて使うことで、いずれかの回線が不調でも安定して配信ができるのではないかと考えられます。
まとめ
AWS re:Invent2019会場であるラスベガスからの「Developers.IO 2019 in Las Vegas」配信について、2019年の機材変更ポイントや配信本番に起きたネットワークトラブル、その原因や対策などについてまとめてみました。正直なところ、昨年そして今年の下見の段階でネットワークについては（ホテルのWi-Fiを使うことで）問題がなかったため、まったく不安視していませんでした。予備回線としてのモバイル回線の動作確認までしておけば、代替案としてのネットワーク切り替えもできたのかもしれません。とはいえ、現場で使える時間なども考慮すると悩ましいところではあるのかなぁとも思います……。2020年もやるとしたらどうなるのか！？ボンディングのような利用できるソリューションなどあればそれも取り入れることも考えていければと思います！
![[レポート] インシデント発生に備えるための議論をする tabletop「Incident response tabletop: Supply chain」 #GHJ205-R #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
![[レポート]re:Invent 2024のEXPO会場で救急セットを作ったりして #GiveBack しよう #AWSreInvent #ACT126](https://devio2024-media.developers.io/image/upload/v1733389602/user-gen-eyecatch/myjtprkzjjcwvxmf8enu.png)
